🌿 브랜치 관리 전략 (Branch Management Guide)

NOTE

브랜치 네이밍 체계, 작업 흐름, MR 작성 가이드를 정리한 Git 브랜치 전략 문서.

본 프로젝트의 효율적인 협업과 코드 품질 관리를 위해 아래의 브랜치 전략을 준수합니다.

---

📌 가이드 내용

1. 브랜치 체계 (Naming Convention)

브랜치는 목적에 따라 세 가지 계층으로 구분하여 운영합니다.

분류	브랜치 형식	설명
운영 브랜치	main	최종 배포용 최상위 브랜치 (직접 Push 불가)
프로젝트 작업	[프로젝트명]/main	프로젝트별 기준 브랜치 (main에서 파생)
프로젝트 개발	[프로젝트명]/feature/[작업명]	기능 개발, 버그 수정 등 일반 작업 ([프로젝트명]/main 파생)
SI 리팩토링	feature/[작업명]	SI 리팩토링 전용 독립 작업 브랜치

---

2. 작업 흐름 (Workflow)

2.1 브랜치 생성 규칙

새로운 작업을 시작할 때는 아래의 명명 규칙을 준수하여 생성합니다.

형식: [prefix]-[작업내용]_[작업자]_[날짜]

• 일반 작업 예시: git checkout -b project-a/feature/add-bank_dev01_260219
• SI 리팩토링 예시: git checkout -b feature/perf-transInfo_dev01_260219

[ Prefix 활용 가이드 ]

Prefix	설명
add	새로운 기능 추가
fix	버그 및 오류 수정
refactor	코드 구조 개선 (기능 변화 없음)
perf	쿼리 튜닝 및 성능 최적화
remove	파일 및 코드 삭제

2.2 코드 반영 및 머지 (Merge)

• main 직접 Push 금지: 모든 코드는 **Merge Request(MR)**를 통해서만 반영할 수 있습니다.
• 최신 상태 유지: 브랜치 생성 전 항상 상위 브랜치에서 pull을 받아 최신 상태를 유지합니다.

2.3 브랜치 관리 수칙

1. 기능 단위 생성: 하나의 브랜치에서는 하나의 기능(또는 이슈)만 처리하는 것을 원칙으로 합니다.
2. 단위 커밋: 통합테스트 수정 등 작은 범위의 작업 시에는 fix-test 등으로 명확히 구분하여 커밋합니다.
3. 반영 후 즉시 삭제: MR이 완료된 브랜치는 즉시 삭제합니다. (미삭제 시 3개월 주기 정기 삭제)

---

3. Merge Request 작성 가이드

모든 MR은 팀원 간의 원활한 리뷰를 위해 아래 양식을 준수하여 작성해 주세요.

3.1 주요 작성 항목

1. 작업 배경: 작업을 수행하게 된 이유나 기획 의도 (예: 쿼리 속도 개선, SI 요청 반영 등)
2. 주요 변경 사항: 코드 수준에서의 수정 핵심 내역 요약 (예: 인덱스 추가, 조인 방식 변경 등)
3. 테스트 결과: 정상 작동 확인 결과 (예: ./gradlew build 성공 여부, 결과 스크린샷 등)
4. 관련 이슈: 연관된 이슈 번호 (예: #123)

3.2 머지 옵션 (Merge Options) 설정

MR 생성 화면 하단에서 아래 옵션을 확인해 주세요.

옵션 (Options)	설명	필수 여부
Squash commits…	여러 개의 커밋을 하나의 깔끔한 커밋으로 합쳐서 머지합니다.	✅ 필수
Delete source branch…	머지 완료 후 작업 브랜치를 원격 저장소에서 자동 삭제합니다.	⚠️ 권장

---

💡 작성 팁 및 주의사항

• 쿼리 튜닝 시: 성능 개선 수치(2.0s -> 0.2s)나 실행 계획(Explain Plan) 비교 결과를 첨부해 주세요.
• 커밋 관리: Squash 머지 시, 최종 커밋 메시지는 feat: [결제] PG사 연동과 같이 명확한 제목으로 수정 바랍니다.
• 작업 최소화: 리뷰 효율을 위해 작업 단위는 가급적 작게 유지합니다.

관련 문서

• (Git) COMMIT 컨벤션 가이드 - 핵심 개념 및 특징 정리 — 같은 회사 Git 워크플로에서 브랜치 전략과 짝을 이루는 커밋 메시지 작성 규칙
• (Git) 오픈소스 기여 방법 및 순서 — 이 회사 GitLab 브랜치 전략을 오픈소스 GitHub fork 워크플로와 대비시켜 설명하는 노트